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ABSTRACT 



"Multilevel atomicity", a new correctness criteria for database concurrency control, is defined. It 
weakens the usual notion of serializability by permitting controlled interleaving among transactions. It 
appears to be especially suitable for applications In which the set of transactions has a natural 
hierarchical structure based on the hierarchical structure of an organization. A characterization for 
multilevel atomicity, in terms of absence of cycles in a dependency relation among transaction steps, 
is given. Some remarks are made concerning implementation. 
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1. Introduction 

Popular models for database concurrency control [RSL, BG] are based on a set of "entities", 
either centralized or else distributed among the nodes of a network. These entities are accessed by 
users of the database through "transactions" , which are certain sequences of steps involving the 
individual entities. The steps are grouped into transactions for at least three distinct purposes. First, 
a transaction is used as a logical unit : it describes a self-contained task within which local state 
information can persist; thus, the results of earlier steps can be recorded so as to affect the later steps 
of the same transaction. Second, a transaction is used to define atomicity : all of the steps of a 
transaction form a logical atomic unit in the sense that it should appear to users of the database that 
all of these steps are carried out consecutively, without any intervening steps of other transactions. 
This requirement that transactions appear to be atomic is called "serializability" in the literature 
[EGLT.RSL.BG] and has been widely accepted as an important correctness criterion for databases. 
Third, a transaction is used as a unit of recovery : either all of the steps of a transaction should be 
carried out, or none of them should; thus, if a transaction cannot be completed, its initial steps must 
be "undone" in some way. 

While the same unit is generally used for all three purposes, I think it is more appropriate to use 
different units. In particular, the logical unit (henceforth called the "transaction") should be as large 
as possible, for maximum transaction expressiveness. If transactions are long, then the usual 
requirement of serializability of transactions is so strong that it excludes efficient implementation of 
many application databases. Therefore, another mechanism must be superimposed on the 
transaction mechanism, in order to define atomicity. The unit of atomicity should be as small as 
possible, for maximum concurrency. The unit of recovery could be anywhere in between; one would 
probably not want to roll back very long transactions, but might want to roll back beyond a unit of 
atomicity. 

In this paper, I consider the simultaneous use of a large logical unit and a smaller unit of atomicity. 
I imagine a database world in which processing is carried out by very long, possibly even infinite 
transactions. Each transaction can rely on its memory of previous processing to determine its later 
processing. From time to time, a transaction reaches a "breakpoint" where other transactions are 
permitted to interleave. When a transaction resumes processing after a breakpoint, it can recall its 
activities prior to the breakpoint. 

Application databases are modelled here as centralized , concurrent systems of transactions and 
entities. Application databases exist at a purely logical level. Thus, it is appropriate to regard them as 
centralized even though they are to be "implemented" by a distributed system. The steps of different 
application database transactions might be allowed to interleave in various ways; the set of allowable 



interleavings is determined by the application represented, at one extreme, it might be specified that 
alt allowable interleavings be serializable; this amounts to requiring that the application database be a 
centralized serial database. At the other extreme, the interleavings might be unconstrained. In a 
banking database, a transfer transaction might consist of a withdrawal step followed by a deposit 
step. In order to obtain fast performance, the withdrawals and deposits of different transfers might be 
allowed to interleave arbitrarily, even though the users of the banking database are thereby presented 
with a view of the account balances which includes the possibility of money being "in transit" from 
one account to another. I don't think that this interleaving represents an inconvenience to be 
remedied when technology advances further; rather, this interleaving represents the appropriate 
activity for this application. In between the two extremes, there are many other reasonable 
possibilities. 

A framework is required for describing sets of allowable interleavings, Such a framework should 
specify interleavings in a way which is suitable for use by a concurrency control algorithm. At the 
same time, the sets of interleavings which can be specified should include the allowable interleavings 
for important application databases such as those for banking. 

As a first approximation to a specification method, we might associate with each transaction its 
"atomicity" , formally described by a set of "breakpoints" between different sets of consecutive steps. 
Steps not separated by a breakpoint would always be required to occur atomically, (at least from the 
point of view of the system users). As a special case of this definition, if there are no breakpoints for 
any transaction except at the beginning and end, then this requirement is simply the usual 
requirement of serializability. As another special case, if there are always breakpoints between every 
pair of steps of each transaction, then this requirement allows arbitrary interleaving. In addition, 
many intermediate cases are possible. 

However, this definition is not sufficiently general to express all commonly-used constraints on 
interleavings. For example, consider a banking system with transfer transactions as described above. 
Transfers might be allowed to interleave arbitrarily with each other. However, one might also want to 
have another type of transaction, an "audit transaction" [FGL], which reads all of the account 
balances and returns their total. This audit transaction should probably not be allowed to interrupt a 
transfer transaction between the withdrawal and deposit steps, for then the audit would miss counting 
the money in transit. That is, the entire transfer transaction should be atomic with resoect to the 
entire audit transaction. Thus, the same transfer transaction should have one set of breakpoints with 
respect to other transfers, and another set with respect to audit transactions. 

This example is representative of a fairly general phenomenon: it might be appropriate for a 
transaction to have different sets of breakpoints with respect to different other transactions. That is, 



each transaction might allow different "views" of its activity to different other transactions. Thus, a 
natural specification for allowable interleavings might be in terms of the "relative atomicity" of each 
transaction with respect to each other transaction, rather than just in terms of each transaction's 
(absolute) "atomicity". 

In this paper, a formal definition is given for a type of relative atomicity, called "multilevel 
atomicity". This definition is probably not general enough to describe all conceivable interesting sets 
of interleavings. However, it is quite adequate for many applications, and appears especially suited 
for describing activities of hierarchical organizations. A virtue of this definition is that any set of 
interleavings thus defined has a simple characterization, in terms of absence of cycles in a particular 
dependency relation among transaction steps. This characterization ought to be useful in the design 
of concurrency control algorithms for multilevel atomicity. 

Other researchers [L,GLPT,G,C] have also noted that the usual notion of serializability needs to 
be weakened. In particular, [G] contains interesting preliminary work on specification and 
concurrency control design, for certain non-serializable interleavings. In fact, the multilevel atomicity 
of this paper is a generalization of the two-level atomicity described in [G] under the designation 
"compatibility sets". 

The bank transfer - audit example is explored in [L,FGL]. The solution presented in [FGL] has the 
particularly pleasant property that the audit does not stop transactions in progress. 

The organization of the rest of the paper is as follows. In Section 2, some examples are given of 
the sorts of applications for which multilevel atomicity is suited. In Section 3, a formal model is given 
for application databases. In Section 4, multilevel atomicity is defined. In Section 5, the 
characterization theorem is stated and proved. Section 6 contains discussion of the possible uses of 
the characterization theorem for concurrency control design. Section 7 contains discussion, of the 
relationship of multilevel atomicity to the "nested transaction" model of [M f R,LS,Ly]. 

Much work remains to be done, in designing and evaluating concurrency control algorithms for 
multilevel atomicity. It remains to see whether new concurrency control algorithms which achieve 
multilevel atomicity can be made to operate much more efficiently than existing concurrency control 
algorithms which achieve serializability. It also remains to determine whether these weaker notions 
than serializability are useful for describing the constraints required for real-world database 
applications. 



2. Examples 

Definitions and claims will be illustrated with examples. Many of the illustrations will be derived 
from the following applications. 

Application 1: Banking 

This example expands on the scenarios described in the Introduction. 
The database for the Big Bucks Bank consists of individual accounts. Bank 
customers are permitted to manipulate their own accounts in the usual ways. 
They are also permitted restricted access to the accounts of others (say, to 
deposit money). As an additional complication for this example, customers 
are grouped into families, each of which shares control of a common set of 
accounts. Frequently, a family member will move money between family 
accounts. Transfers of money from the accounts of one family to the 
accounts of another family are also fairly common; they are often contingent 
upon some condition involving the amount of money in one of the originating 
accounts, or else involving the total amount of money in all the accounts of 
the originating family. Occasionally, the bank wishes to take a complete audit 
of the contents of all accounts, perhaps using the result to enter a calculated 
interest amount into a special account. Also, creditors frequently require an 
audit of the contents of all the accounts of particular families. 

The interleaving constraints are very strong for the bank audit: it should 
be atomic with respect to all the other transactions, and conversely. The 
interleaving constraints for credit audits and customer transactions are much 
less severe: for example, as long as the total of the accounts of any particular 
family is "correct" (e.g., no money is in the process of being moved from one 
family account to another), it should be fine for any creditor or customer 
transaction to obtain access to that family's accounts. Finally, the interleaving 
constraints for customer transactions from customers in the same family are 
even less severe (perhaps nonexistent). Presumably, family members trust 
each other enough to allow arbitrary interleaving of accesses to individual 
accounts (or can be prevailed upon to do so by having to pay less for 
arbitrarily-interleaved service). 

It might sometimes be the case that there are some precise database consistency requirements which 
can be used to determine which interleavings are allowable. For example, the condition that a 
particular family's total be a correct representation of its assets, might be used above to determine 
W here certain interleavings can occur. More usually, however, I expect that such data consistency 
constraints will be imprecisely understood, very complicated to state, and very difficult to check. I 
prefer to shift emphasis to the transactions themselves rather than the data. When several 
transactions are allowed to interleave to a particular degree, I assume it is because they share 
sufficient understanding of their permitted activities to be willing to allow each other access to some 
of their partial results. The exact nature of this shared understanding is highly dependent on the 
semantics of the application. 



Application 2: Computer-Aided Design 

Utopian Planning, Inc. is an organization which develops detailed plans for 
design of small cities. The organization consists of a large number of 
specialized experts: architects, plumbers, traffic engineers, electrical 
planners, residential-industrial zoning planners, pollution experts, energy 
efficiency experts and landscape planners, to name a few. Since there are a 
large number of experts in some of the categories, these categories are often 
further subdivided into teams. There is also a public relations department, 
which has the job of describing the plans to customers intending to build 
small cities. 

Utopian's database for each city consists of the latest plan for that city. All 
the experts are constantly making changes appropriate to their specialties. 
These changes interact in very complicated ways. The public relations 
department requires "snapshots 11 which describe some reasonable recent 
version of the plans, satisfying some loosely-defined notion of consistency. 

Interleaving requirements here are strongest for the snapshots vs. the 
changes: it is preferred that snapshots be atomic with respect to all changes, 
and vice versa. Among the changes, a large amount of interleaving is allowed; 
each group of experts expects that the version of the plans on which it begins 
its work satisfies some minimal consistency constraints required by all the 
groups of experts. However, this version need not be "sufficiently consistent* 1 
to show to customers. Experts within a common specialty share a large body 
of knowledge about their specialty. Therefore, by agreeing to respect certain 
consistency constraints appropriate to their specialty, they can permit their 
changes to interleave to a high degree. Experts within the same team share, 
in addition to knowledge about their specialty, knowledge about the team's 
working methods and habits. On this basis, changes made by members of the 
same team are permitted to interleave to an extremely high degree. 

In this example, data-determined consistency constraints would be especially difficult to describe. 
Nevertheless, it might be easy to describe which groups of transactions "trust each other'* to respect 
appropriate consistency constraints. Note that I have not even described any structure for the 
database in this example. This structure is extremely complex, and is not required for the approach 
taken in this paper. 
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3. Application Databases 

In this section, we define precise notions of "transaction" and "application database". 
Application databases consist of a set of transactions together with a set of "correct" interleavings 
for executions of those transactions. A notion of "equivalence" for transaction executions is defined: 
two executions are equivalent provided they look the same to each transaction and to each entity in 
the database. The "correctable" executions are defined to be those which are equivalent to correct 
executions. 

3.1 . A Model for Asynchronous Parallel Processes 

Application databases will be formalized using a variant of the model of [LF] for asynchronous 
parallel computation. 

The basic entities of the model are processes (nondeterministic automata) and yarJabiSS- 
Processes have states (including start states and possibly also final states), while variables take on 
values . An atomic execution step of a process involves accessing one variable and possibly changing 
the process' state or the variable's value or both. A system of processes is a set of processes, with 
certain of its variables designated as internal and others as external . Internal variables are to be used 
only by the given system, and come equipped with particular initial values. External variables are 
assumed to be accessible to some "environment" (e.g., other processes or users) which can change 
the values between steps of the given system. 

The computation of a system of processes is described by a set of executions- Each execution is 
a (finite or infinite) totally ordered set of steps which the system could perform when interleaved with 
appropriate actions by the environment. Each execution is composed of steps of the processes of the 
system. 

For any execution e of a system of process, the dependency partial order. ^ e , of the steps of e is 
defined as follows. For every pair of steps, a, /S, in e, let a < e if a precedes)? in e and either 

(i) a and fi involve the same process, 
or (ii) a and /? access the same variable. 

In this paper, I generalize [LF] slightly by allowing executions to be arbitrary totally ordered sets. 
Therefore, I require the technical assumption that each step in an execution e has only finitely many 
< predecessors. The consistency requirements for executions are as follows. Each internal 
variable starts with its initial value; each execution step involving a process, p, begins with p in the 
same state which p had at the end of the previous step involving p; each execution step accessing an 



internal variable, x, begins with x having the same value which x had at the end of the previous step 
accessing x. 

I relax the definition of "execution" in [LF] in one further way, by removing the assumption of 
fairness. That is, I do not require here that each process continue to take steps until it reaches a final 
state. 

If e is an execution of a system, S, of processes, then every total ordering of the steps of e which Is 
consistent with < is also an execution of S, having the same sequence of values for each variable 
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and the same sequence of states for each process. We say that two executions, e and e\ of S are 
equivalent if < is identical to < a , . 

3.2. Transactions, Application Databases, Correct and Correctable Executions 

My notion of an application database is a centralized, concurrent system consisting of 
transactions acting on entities, together with a set of correct interleavings of the steps of those 
transactions, this is modelled very directly in the model of Subsection 3,1: transactions are simply 
formalized as processes, while entities are formalized as variables. More precisely, an application 
database (S,C) consists of a system S of processes, where all variables of S are internal (i.e., internal 
to the system), together with a subset C of the executions of S. The processes are called transactions, 
while the variables are called entities . The elements of C are called correct executions. The 
assumption that the variables are internal says that the entities are only accessed via the transactions. 

This definition gives a very general notion of an application database. The (indivisible) steps of 
transactions are arbitrary accesses to entities, not necessarily just reading or writing steps (although 
these two types of steps are permissible special cases). Transactions can branch conditionally: for 
example, based on the values encountered for certain entities, they might access different entities at 
later steps. This model of a transaction is general enough to include most others in the literature. It 
also includes some other notions usually regarded as somewhat different from ordinary transactions: 
The "transactions with revoking actions" in [G] are a particular type of nondeterministic transaction 
in the present model. 

If (S,C) is an application database and e is an execution of S, we say that e is correctable provided 
e is equivalent to some e' € C. 



Exam ple : 



If C is the set of serial executions of the transaction system [EGLT], then 
the correctable executions are just the usual serializable executions. 



4. Multilevel Atomicity 

4.1. Motivation 

One would like to be able to define particular application databases and have a (centralized or 
distributed) system able to "implement" them. That is, the system should "simulate" (in some sense 
which I will not specify) only correctable executions for the transactions. For arbitrary choices of C, 
this task could be very difficult. 

For the case where C is the set of serial executions, concurrency control theory provides help. A 
basic theorem [EGLT, BG] characterizes the serializable executions as those having an absence of 
cycles in a certain relation describing dependencies among transactions. Thus, one can insure 
serializability by explicitly preventing unwanted cycles (using such devices as two-phase locking 
[EGLT] and timestamps [L]). 

In this section, I restrict the form of C so that a similar cycle-free characterization can be obtained. 
The particular method of restriction I use is to group transactions into nested classes. Those which 
are more closely related in the nesting structure will be permitted to interleave at a finer level of 
atomicity. This structure has the advantage that it allows breakpoint specifications for each 
transaction to be given solely in terms of nesting level. Nested classes are appropriate for describing 
the examples given in Section 2, and other examples which model activities of hierarchical 
organizations. 

4.2. Coherent Relations 

The definitions of this subsection are presented at an abstract level (using sets and partial orders) 
because they will be used to prove a general combinatorial lemma in Subsection 5.1, 

A k- nest , n, for a set X assigns an equivalence relation w(i) to each i, 1 ^i<k, in such a way that: 

a. tt(1 ) consists of exactly one equivalence class, 

b. w(k) consists of singleton equivalence classes, and 

c. each »(i) is a refinement of its predecessor, w(i-1). 
If x,x' € X, then level (x,x') denotes the largest i for which (x,x') € n{\). 

Thus, pairs with higher-numbered levels are more closely related, 

We will consider cases where X is a set of transactions, as in the following two examples. 
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Example (Banking): 

The set X consists of customer transactions, bank audit transactions and 
creditor transactions. A 4-nest describes the relevant relationships among 
transactions. w(1) relates all the transactions, m (2) relates all customer and 
creditor transactions and places each bank audit transaction in a singleton 
class. w(3) refines w(2) by relating only those customer transactions 
belonging to a common family. w(4) consists entirely of singleton classes- 

Example (Computer-Aided Design): 

The set X consists of snapshot transactions and modification transactions. 
A 5-nest describes the important relationships. w(1) relates all the 
transactions. w(2) groups all modification transactions together and all 
snapshot transactions together. w(3) refines *(2) by relating only those 
modification transactions belonging to a common specialty, and m{4) refines 
?r(3) by relating only those belonging to a common team. Finally, *(5) 
consists of singleton classes. 

Next, I describe sets of breakpoints within a totally ordered set, one set of breakpoints for each of 
several "levels", in such a way that the higher level sets of breakpoints always include the lower level 
sets. The totally ordered set should be thought of as the set of steps of some execution of a particular 
transaction. 

If (X, <) is a total order, then an equivalence relation, s, on X is said to be a < - segmentation 
provided that a ~ p and a < y < fi together imply a se y. That is, each equivalence class is a 
segment consisting of consecutive elements of X. 

Breakpoints will be described formally by describing the segments between the breakpoints, as 
follows. Once again, a k-nest (this time for the steps of the transaction) is useful. If (X, <) is a total 
order, then a k-level breakpoint description . B, for (X, <>) is a k-nest for X such that each B(i) is a ^ - 
segmentation. 

Exaippl? (Bankjnfl); 

Let the elements of (X, <) be w r <o 2 , w 3 , 8 V « 2 , in < order. Then B given 
as follows is a 4-level breakpoint description for (X, <): 

B(1Vs only class is {u> v <o 2 , « 3 , 8 V 8 2 ), 
B(2)'s classes are {<o v <o 2 , <o 3 ) and {8 V 8 2 }, 
B(3)'s classes are {u^}, {a> 2 }, {<*> 3 }, {8 J and {8 2 } t and 
B(4)'s classes are {to^, {a> 2 }, {^ 3 }, {5^ and {fi 2 }. 
Intuitively, <o r <o 2 , w 3 , 8 V 8 2 might represent the sequence of steps of a 
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particular execution of a funds-transfer transaction. Steps « r <o 2 and « 3 
represent withdrawals from accounts belonging to the family originating the 
transaction. The amounts obtained by these withdrawals depend on the 
amounts which are discovered to be in the accounts. Steps 5 1 and 8 2 
represent deposits to two arbitrary other accounts (say, a fuel-bill account and 
an entertainment account). The amounts deposited in the two accounts might 
depend on the amount discovered to be already in the first account. B(l)and 
B(4) just represent the extreme cases of atomicity. B(2) represents the 
breakpoint (between w 3 and 5.,) where other customer and creditor 
transactions (but not bank audit transactions) are permitted to interleave. 
B(3) represents the breakpoints permitted for other transactions of the same 
family as the given funds-transfer transaction. 

Next, I want to describe sets of breakpoints for all the transactions in a given set. If T is a set (to 
be thought of as a set of transactions), then a k-level interleaving specification, 3, for T is a collection 
of triples (X t , £ f B t ), one for each t € T, where {(X t , < t ): t € T} is a collection of disjoint totally ordered 
sets (to be thought of as the sets of steps of particular executions of all the transactions in T) and 
each B t is a Mevel breakpoint description for (X^ <; t ). 

Example (Banking): 

LetT = {Wy. For each t., let (X t ,< t ) be the sequence ^.w^^, 
JL , S , and let B. be defined analogously to the previous example: 

1 1 Is! !• 

B t (1Vs only class is {w jr a> j2 , u.^ S. v 5 i2 ) , 

B t .(2)'s classes are {w. v w i2 , w^} and { 8 {V 5 j2 ), etc. 

Then 5 = {(X t , < t , B t }: t € T} is a 4-level interleaving specification for T. 

Intuitively, t r t 2 and t 3 represent different funds-transfer transactions, 
which might be from the same or different families. 3 gives both a sequence of 
steps and a breakpoint description for each of t 1§ t 2 , tj. This combination of 
descriptions is intended to be used to help define how t v t 2 and y are 
permitted to interleave. (Of course, in order to define the permissible 
interleavings, we must also know which of t,, t 2 and t 3 are from common 
families.) 

Next, I define an important condition for a relation, R, on U{X t : t € T}. I want to express the fact 
that R preserves all of the individual < t orderings and also respects the restrictions expressed by the 
given collection of breakpoint descriptions. In most cases of interest, R will be a partial order. 

Let m be a k-nest for T, 3 * {(X t , < t , B t ): t € T} a k-Ievel interleaving specification for T, R a 
relation on U{X t : t € T}. Then R is coherent for it and 3 provided the following two conditions hold. 
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(a) R contains each partial order ^ t< 

(b) Assume level # (t,t') * I. 

Assume a, a' € X t and a < t a' and (a, o') € B t (i). 

Assume ft € X f . 
lf(a,0)€R,then(a\j8)€R. 

Intuitively, this latter condition says the following. If a step, /3, of one transaction follows (in R) a 
step, a, of another transaction, t, then also follows any other step, a\ of t which follows a but 
precedes any breakpoints of the appropriate level. Note that the breakpoints are defined solely in 
terms of the nesting level for the two transactions. 

Eyamp'fri 

Let k = 3, T = {t v t 2 , t 3 } and let w(2)'s classes be {t v t 2 } and {t 3 >. (»(1) 
and w(3) are uniquely determined.) For each t, € T, let (X,, < t ) be the 
sequence a j1 , a j2 , a j3 , a w , and let B t (2)'s classes be {a lV a, 2 } and {0,3, a^}. 

(B,(1) and B. (3) are uniquely determined.) 

i i 

Let R 1 be the transitive closure of all the ^ t plus the pairs (« 12 , a^), 
(a^, a 13 ), (a 14 , o 31 ) and (a 24 , agg). Then R 1 is a coherent partial order. 



Let R 2 be the transitive closure of all the < plus the pairs (a^, ot^), (« 21 , 
« 13 ), (a 1f , o 31 ) and (a 21 , o M ). Then R 2 is a non-coherent partial order. 



Let R 3 be constructed similarly to R 2 , except with (a 31 , «„). in place of 
(a 1v a 31 ). Then R 3 is a non-coherent partial order. 

If a given relation R is not coherent, it is sometimes useful to consider the smallest coherent 
relation containing R. This can be defined as follows. Given a set T, a k-nest it for T, a k-level 
interleaving specification J .- '{(X,, £,, B t ): t € T} for T and a relation R on U{X,: t € T} containing all 
the <. , define the coherent closure of R with respect to it and 5 to be the relation obtained from R by 
closing under condition (b) of the coherence definition. 



Example; 



In the previous example, the coherent closure of R 1 is R 1 itself. The 
coherent closure of R 2 is just the partial order R r The coherent closure, R 4 , 
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of R 3 is not a partial order, however. (Since (« 31 , a n ) € R 4 , it follows that 

(<*33' tt 11> € R 4" We kn0W (<X 1V a 22> € R 4' SlnCe (flE 2V a 33> € R 4' * f °"° WS ** 

(a^, agg) € R 4 . Hence, R 4 contains a cycle.) 
It is easy to see that R is extendable to a coherent partial order if and only if the coherent closure 
of R is a partial order. 

4.3. Definition of Multilevel Atomicity 

In contrast to the preceding subsection, the definitions of this subsection deal explicitly with a 
system S of transactions. I use the abstract definitions in the preceding section to help describe sets 
of allowable execution sequences. Intuitively, transactions are grouped in nested classes so that for 
each t, the set of places where a transaction t' can interrupt t is determined solely by the smallest 
class containing both t and t\ Moreover, smaller classes determine at least all of the breakpoints 
determined by containing classes (and possibly more). This says that transactions which are grouped 
in a common small class might have many relative breakpoints (i.e. can interleave a great deal), white 
transactions which are only grouped in a common large class might have fewer relative breakpoints 
(i.e. cannot interleave very much). 

For each pair of transactions t and f, I must describe the places at which t is permitted to be 
interrupted by steps of t\ Since the transactions need not be straight-line programs, but can branch 
in complicated ways, I am forced to describe separately the places at which each different execution, 
e, of t can be interrupted by steps of t\ 

A Mevel breakpoint specification . *B. for a system, S, of transactions is a family, {B tfl : t is a 
transaction of S, e an execution of t}, where each B t e is a k-level breakpoint description for the steps 
of e, totally ordered according to their occurrence in e. (Formally, the elements of the ordered set of 
steps are pairs (i,o.); where a. is the ith step of e.) 

A k-nest, ?r, for the transactions of a system S, and a k-level breakpoint specification, a, for S can 
be used in a straightforward way to define an application database. Namely, for any execution e of S, 
define a k-level interleaving specification 31%. e ) * {(X t , < t , B t ): t € T} by letting T be the set of 
transactions appearing in e, e t be the execution of t occurring as a subsequence of e, X t be the set of 
steps of t occurring in e t , < t be the order in which those steps occur in e, and B t be B t e € SB. 5{%e) is 
just the natural interleaving specification which is derived from the particular execution e using the 
given k-level breakpoint description <&. An execution e of S is multilevel atomic for n and % provided 
the total ordering of steps in e is coherent for tt and 5{%e). Let C(n.%l denote the set of executions 
which are multilevel atomic for m and $. Then the application database of interest is (S, C(7r,?E )). 

Thus, we use the multilevel atomic executions as the "correct" executions. In Section 5, we will 
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develop a characterization of the corresponding "correctable" executions. Note that "multilevel 
atomic" generalizes "serial", as follows. 

Example; 

If k = 2, then w(1) relates all transactions, while *r(2J only relates 
transactions to themselves. There is only one possible breakpoint 
specification $. Namely, for each t and e, B te (1) groups all steps together, 
while B te (2) divides the steps into singleton sets. In this case, the multilevel 
atomic executions are just the serial executions* 



5xampte; 



The reader is referred to [G] for treatment of a special case of our 
definition corresponding to k = 3, where B t e (2) consists of single steps, for all t 
and e* That is, transactions in. a common w(2) class can interleave arbitrarily, 
but transactions not in a common w(2) class must be serialized with respect to 
each other. The "multilevel" definition of this paper also allows intermediate 
degrees of interleaving as well as the two extremes represented in [Q]. 



Ex?mpl3 (B^nKIng); 



Let the set of transactions be T U A, where T = {t,, t 2 , t 3 ) is a set of 
transfers and A = {a} consists of a single bank audit. Let m be the 4- nest with 
*(2) = {t v t 2 , 13}, {a} and *(3) = {t r tj, {t 3 }. {a}. 

Consider t v for example, t, is intended to withdraw $100 from the 
combined accounts A, B and C, and deposit the withdrawn amount in D and 
E. The precise behavior of t 1 depends on the amounts encountered in the 
various accounts, t, will examine A, B and C sequentially, attempting to 
obtain $100 as soon as possible. If t 1 is able to obtain $100 from A alone or 
from just A and B, then t, need not access the remaining accounts. If t, 
accesses all three accounts and succeeds in obtaining less than $100, t| will 
proceed to D and E with the lesser amount. t 1 tries to leave D with at least 
$1 25; any available money over $1 25 will be deposited in E. 

Thus, t 1 has many possible execution sequences. Two are described 
below. 



e^ Access A, see $20, leave $0. 

Access B, see $150, leave $70. 
Access D, see $20, leave $120. 

e 2 : Access A, see $0, leave $0. 

Access B, see $15, leave $0. 
Access C, see $70, leave $0. 
Access D, see $1 1 0, leave $1 25. 
Access E, see $30, leave $100. 



15 



Let $ * {B : t € T U A, e an execution for t) be the 4 - level breakpoint 
specification for e T U A defined as described in the banking examples in 
Subsection 4.2. For example, B t (2) has classes {u v w 2 , « 3 }, {8,, 6 2 ). 

where w r u 2 , w 3 , fi v fi 2 represent the five steps of e 2 , in sequence. (For 
all transfers, B, e (2) groups withdrawal steps together and deposit steps 
together.) B. , (3) consists of singleton classes. 

1 2 

Now, for each t, fix a corresponding execution e i with steps w |V w j2 , 8 (1 , 
8 j2 . Fix an execution e of a with steps a y o 2 , a 3 . If the following is an 
execution (i.e., if the successive values of entities match up properly), then it 
is multilevel atomic for n and $: 

W 3V "32' w 11' W 21' W 22' w 12' fi 31' 5 32' S 21' *1V 5 22' fi 12' *V *2' a V 
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5. Characterization Theorem 

In the previous section, a particular style of definition for C, the set of correct sequences, was 
given. One would like a centralized or distributed processing system to "simulate" only correctable 
executions. (As I have previously mentioned, I will not be precise about the definition of 
"simulation".) In this section, a characterization theorem is proved for correctable executions. This 
theorem is analogous to the absence-of cycles characterization for serializability [EGLT]. 

5.1 . A Combinatorial Lemma 

In this subsection, I state a combinatorial lemma which will be used in the next section to derive a 
necessary and sufficient condition for correctability (equivalence with multilevel atomicity). The 
lemma requires only the abstract definitions in Subsection 4.2. 

For this subsection, let T be a fixed set, let w be a fixed k-nest for T, and let 5 = {(X t , ^ t , B t ): t€T} 
be a fixed k-level interleaving specification for T. Let "coherent" mean "coherent for it and 5", and 
write "level" for "level/. 

Lemma 1 : If <. is a coherent partial order, then there Is a coherent total order <.' 
which contains <|. 

Proof: See Appendix. 

Example; 

Let R 1 be the coherent partial order given in Subsection 4.2. Then there 
are two coherent total orders containing R r namely: 

a l1- a 12' a 21' a 22' a -W a H' a 23' a 24' a 3V tt 32' a 33' tt 34 

and 

a 1v o 12 , a 21 , a^, a a , a 24 , a 13> a u , a 31 , a^, a^, <* M . 

5.2. The Theorem 

The characterization result can now be stated. For this subsection, let S be a fixed set of 
transactions, -a a fixed k-nest for S, IB a fixed k-level breakpoint specification for S. Let the "correct" 
executions denote those in C(ir,9&) (i.e. the multilevel atomic executions), and the "correctable" 
executions denote those which are equivalent to multilevel atomic executions. 

Theorem 2: Let e be an execution of S. Then e is correctable if and only if the 
coherent closure of <„ with respect to ir and J(S,e) is a partial order. 

Proof: First, assume e is correctable. This means that < e is extendable to a total 
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order which is in C(w,$), i.e. which is coherent for tt and 5(%e). Then surely the coherent 
closure of < , which is the smallest coherent relation containing <, must be acyclic. 

•—•0 o 

Conversely, assume that the coherent closure of <J e with respect to ir and 3{%e) is a 
partial order. Then the lemma implies that there is a coherent (for n and 5($,e)) total order 
which includes the coherent closure of < e , and whiich therefore includes £ e - Thus, e is 
correctable. 



Example (Banking); 

Consider the last example of Subsection 4.3, where the transactions are t v 
L, t and a, and fix executions as before. Assume the accounts accessed are 
as follows. 



W 11 :A 


« ai :A 


a, 31 : B 


a.,: A 


« ia :B 


W 22 :C 


«32 :D 


a 2 :B 


a„:c- 


8 21 :E 


«31 :F 


a 3 :C 


S 12 :D 


«22 :G 


V H 





If the following is an execution, then while it is not multilevel atomic for v 
and % it is correctable: 6> 1V « 31> o> 21 , a> 12 , a v a 2 , u^, 8 1V « 3 i S 2 1' *22' w 32' 

8 12 j5 31 ,6 32' 

An equivalent multilevel atomic execution is the one given in Subsection 
43. 

On the other hand, if the following is an execution, then it is not 
correctable: w 1v <o 21 , t*> 31 , a v a 2 , a 3 , w 12 » w^, u^, 5 1V S 21 , $ 31 , fi 12 , S^. 

The theorem can be used to verify both claims. 



D 
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6. Concurrency Control 

In this section, I discuss how a concurrency control mechanism might take advantage of some of 
the preceding ideas. I want to design concurrency controls which use the correctness condition 
stated in the theorem of Section 5. 

For definiteness, I use the "migrating transaction" model described in [RSL]. In this model, 
entities of the database reside at nodes of a network of processors, and the transactions migrate from 
entity to entity as necessary, executing some of their steps on different processors. In more detail, a 
transaction t, with start state s, originates at a processor p. A message (p,t,s) is sent to the processor 
owning the entity which t accesses when it is in state s. A processor receiving a message (p.t.s) 
"performs" the indicated step by changing the value of the entity, updating t's state, and sending a 
new message (p.t.s'), where s' is the new state. If s' is not a final state, the message is sent to the 
processor owning the appropriate entity. If s' is a final state, the message is sent back to the 
originator p. In this way, an execution e of the system of transactions is actually "performed" by the 
processors. The total order of the execution is determined by real clock time. 

I consider how to insure that any execution sequence e "performed" by the processors has a 
dependency partial order <. e whose coherent closure is a partial order. 

It will be necessary to make an additional assumption about a breakpoint specification. Namely, in 
order to be able to determine on-line the locations of breakpoints, it is necessary Jo assume a 
"compatibility" condition: if two executions of a transaction share a common prefix e, then either 
both executions have a breakpoint immediately after e, or neither does. 

Assume that the concurrency control generates an execution e of S, and that the concurrency 
control includes some priority scheme and rollback mechanism to insure that no initiated transaction 
gets blocked indefinitely. (Such a scheme is not specified here.) I consider how to insure that the 
coherent closure of < a is a partial order. 

One possible strategy is cycle-detection, using the coherent closure of <£ fl . Namely, if the 
concurrency control does not otherwise guarantee that ^ e is extendable to a coherent partial order, 
the concurrency control might generate explicitly the edges of the coherent closure of ^ e , and check 
for cycles. If a cycle is detected, a priority scheme can be used to determine which steps should be 
rolled back. Presumably, fewer cycles would be detected using the multilevel atomicity definition than 
if strict serializability were required, leading to fewer rollbacks. 

Another approach is cycle prevention - guaranteeing that the coherent closure of <£ e is a partial 
order. One way of doing this might be to delay some steps, as follows. 
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Let be a step of any transaction t'. p first gets "scheduled", thereby locking its entity and 
delaying t\ p does not actually get "performed" until the following is insured. (Note that e refers to 
the order in which steps actually get performed, not the order in which they are scheduled.) Let e^ 
denote the initial segment of e ending with step p. If a is the last step of some transaction t which 
precedes p in the coherent closure of < e , then a level(t, f) breakpoint immediately follows a in t's 
execution subsequence of e„. (This can be accomplished by making p wait until suitable breakpoints 
have been reached, assuming that the concurrency control uses a priority • rollback mechanism for 
preventing blocking.) 

If the property above is guaranteed, for each p, then the coherent closure of < e is consistent with 
the total ordering of steps in e, so it must be a partial order. 

Of course, there are still many difficulties involved in designing a priority ■ rollback scheme to 
guarantee that no transactions block. Another, related difficulty in the design of a mechanism for 
allowing transactions to commit: even though the concurrency control guarantees eventual 
performance of all of the steps of a correct execution e, it does not necessarily follow that the 
concurrency control can determine a particular point in time when each transaction can no longer 
have any of its steps rolled backl This is apparently a greater difficulty for multilevel atomicity than it 
is for ordinary atomicity, since multilevel atomicity allows (even if there are only a finite number of 
entities) an infinite chain of transactions t v t 2 , t 3 ,... such that for each i, there are steps a of t, and p 
of tj 1 with p < e a. This means that it is quite plausible that a rollback of steps of t, + 1 can cause a 
rollback of steps of t ( , and so on. 
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7. Discussion 

It is interesting to compare multilevel atomicity to the atomicity achieved by the "nested 
transaction model" [M, R, Ly]. The latter model permits transactions to be nested, and then requires 
serializability of transactions at every level, including the top level. 

At first glance, it appears that the nested transaction model is incapable of describing the 
interleavings considered in this paper. Indeed, this is the case if the atomicity units ("transactions" of 
the nested transaction model) are constrained to be the same as the logical units ("transactions" of 
this paper). 

Example (Banking): 

Let T be a set of transfer transactions, A a set of audit transactions. If 
each element of T U A is modelled as a separate top-level transaction in the 
nested transaction model, then elements of T are required to be serialized 
with respect to each other. 

However, the situation is different if the logical units and the units of atomicity are allowed to be 
different. The nested "transactions" of the nested transaction model can be regarded as describing 
the units of atomicity. 

In order to distinguish these from the logical transactions, I will designate the former as "actions". 
A (logical) transaction would be mapped into actions by means of a mapping which distorts the 
transaction's structure. 

Example (Banking): 

Let T = {t v ... , t 4 } be a set of transfers, where each transfer t. consists of 
a withdrawal step <o. followed by a deposit step 8 y Let A as {a r a 2 ) be a set of 
audits, where each audit a. consists of a sequence « h a jn of read- 
account-balance steps. A nested action tree can be used to describe the 
relevant nesting relationships between actions, for each multilevel atomic 
execution. For example, the following tree: 




w x 8j w 2 5 2 



a x\ a \z 



.,/* 



a 21 a n 



'2n 
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can be used to describe an execution in which transactions t 1 and t 2 are 
combined to form a single action. The steps of the two transactions, o> v S v 
w, and 8 2 are all siblings as far as atomicity is concerned. 

There are several possible ways in which « v 8 2 , u 2 and 8 2 might 
interleave. Similarly, t g and t 4 are combined. (Note that the reorganization of 
transactions into actions is not statically determined, but rather depends on 
the particular execution.) With this reorganization, the nested transaction 
model expresses exactly the proper atomicity requirements. 

In a way similar to that described in the preceding example, any set of multilevel atomic 
executions C(w, tt) can be described by a corresponding collection of nested action trees. In each 
such nested action tree, the following property holds. Enumerate the levels of the tree, with the root 
at level 1 . Then all steps appearing below any particular level i node in the tree belong to transactions 
which are w(i) - equivalent. Moreover, (if i > 1), these steps suffice to carry each of the transactions 
involved to a level i-1 breakpoint. In this way, the nested action tree structure follows the k-nest 
structure. 

Although it is possible. for the nested transaction model to describe multilevel atomicity, it is not 
clear to what extent this fact is useful for implementing multilevel atomicity. There are several known 
ways for implementing nested transactions, based on timestamps [R] or two-phase locking [M, LS]. 
Of course, these could be specialized to implement multilevel atomicity. However, I do not know 
whether these specializations provide efficient implementations. This question is a topic for future 
study. 

The new programming language Argus [LS] is based on the nested transaction model. In that 
language, the structure of user programs follows the nested action structure very closely. That is, the 
logical unit and the unit of atomicity are the same. While I suspect that the nested transaction model 
is adequate for describing atomicity, it seems to me that for modelling many situations of Interest 
(multilevel atomicity, conversations between transactions [Ra]), it will be necessary for the logical 
program structure to be different from the atomicity structure. Perhaps both logical structure and 
atomicity are naturally described using nested structures, but the nestings used for those two 
purposes might be different. 

There are several areas remaining for future research. It remains to explore more applications in 
which multilevel atomicity is a helpful descriptive tool. It remains to design detailed concurrency 
controls based on this criterion, and use them to determine whether this generalization of 
serializability can be exploited for increased efficiency. It remains to see whether implementation of 
multilevel atomicity as a special case of the nested transaction model provides reasonable efficiency. 

Most importantly and generally, it remains to identify other situations in which it is useful to 
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distinguish the logical unit from the unit of atomicity (and from the unit of recovery). 
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Appendix: Proof of the Combinato rial Lemma 

Let < (1) denote <,. A sequence of stages numbered 2, .... k is carried out. Each stage, i, inserts 
additional pairs into the ordering relation, yielding <. (i) . Then <' is defined to be ^ (k) . It is shown, 
inductively on I, 1 <i <k, that (a) < (i) is a coherent partial order, and (b) if a € X t and p € X,, , and 
level(t.t') < i, then a and p are < (i) comparable. Conditions (a) and (b) are trivially true for I * 1. 
Conditions (a) and (b) for i = k clearly imply the needed result. 

Stage i (2 ^i £k). 

Partition X » U{X t : t € T} into segments , where each segment is an equivalence class of some 
B t (i-1). 

A segment S is said to bjgigngjg. an element t € T if S Q X,. 

Define a directed graph G whose nodes are all the segments. G contains an edge from segment 
S 1 to segment S 2 exactly if there exist a € S 1( /3 € S 2 with a ^ (M) j8. 

Totally order the strongly connected components of G, f A < f 2 < ... , so that G contains no edges 
from any segment in S to any segment in * n , n < m. Then define < (i) by adding to < (l ' 1) all pairs 
(a, PI where a € S, € S m , p € S 2 € * n , and m < n. 

END 

I now prove the needed properties (a) and (b) for < (i) , assuming that they hold for ^ (M) . 

Lemma 3: < (i) is a partial order. 

Proof: There are no edges in < (l) from o € S 1 € * m to P € S 2 € *„, where n < m. Also, 
all edges in <® not in < (M) go from a € S 1 € * m to p € S 2 € S n , where m < n. Thus, there is 
no cycle in <: (i) involving a new edge. Since <J (M) is a partial order, there are no cycles if 



_ o _ ^ i . tin 

£®.'~ 

Lemma 4: < w is coherent. 

Proof: Assume level (t,f) = j. Assume a, a' € Xj and a <J, a' and (a, a') € B t (j). 
Assume p € X^. Assume a < (i) p. I show that a' <. {i) p. The result is trivial if t ■ t', so 
assume that t* t\ 

GassJLa^P 

By inductive hypothesis (a), < (M) is coherent, which implies the needed result. 



□ 
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Case 2. a <* M) B 

Then o € S t € * m , B € S 2 € * n for some m < n. 

Since a ^ (l) B and < (i) contains < (M) , it follows that B < (M) a, so that a and /? are 
< (M) incomparable. Then inductive hypothesis (b) implies that j (= level(t,t')) ;> I -.1. 
Thus, B t (j) C B,(i-1), so that (a, a') € B,(i-1). Therefore, «' € S r The definition of ^ (i) then 
insures the needed result. 

Lemma 5: For each m, the following holds. If S, S' € * m , S belongs to t and S' belongs 
tot', then (t,t')€w(i). 

* Proof: If not, then some !f m contains a cycle S Q , S v .... S, = S„ of segments such that 
for each j, < j < 1-1, there exist a € S,, B € S j + 1 with a ^ (i1) B and such that two of the 
segments belong to'ir(i) • tnequivalent elements of T. 

Let S and S' be two distinct segments in this cycle, belonging to elements t and f 
respectively, where (i) (t, f) t ir{\), and (ii) any segment S" following S and preceding S' In 
the cycle belongs to some t" which is ir{\) ■ equivalent to t. Then if a is the last (in the ^ t 
ordering) element of S and is the last (in the < t , ordering) element of S', we claim that 
a < (M) B. This is shown by induction on the number of segments following S and 
preceding S' in the cycle. 

Inductive Step . There exists a' € S such that o' < (M) P', where B' is the last step of 
the cycle ■ successor of S. (This is by construction of the cycle and the fact that ^ (, ' 1) 
contains all the total orderings of the individual transactions.) By inductive hypothesis (or 
trivially, if S' itself is the cycle successor), it follows that B' ^ (M) B. Thus, o' <°" 1) B. Now, 
j - level (t,f) < i • 1, by assumption, so B,(M) C B t (j). Since (o', o) € B t (i-1), it follows that 
(a\ a) € B,(j). Coherence of <; (M) implies that a ^ (M) B. 

Applying this claim repeatedly around the cycle shows that there are two distinct 
segments, S and S', such that a £ (M) P and B # 1) «, where a and B are the last steps of 
S and S' respectively. But this contradicts the assumption that < (,1) is a partial order. 

Lemma 6: If a € X t and B € X t „ and level (t,f) < i, then a and B are ^ (i) ■ comparable. 

Proof: By Lemma 5, t and f. do not have any segments in the same strongly connected 
component * m . Thus, a € S 1 € * m , B € S 2 € J n , and m ^ n. But then < {i) is defined to 
contain the pair (a, /3) if m < n, and to contain 05, o) if n < m. 
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